ChatGPT Work（Codex）之道：用管理的逻辑了解和使用AI Agent（领导篇）
之前在《[[9-兴之所志/AI办公之道/ChatGPT Work（Codex）之道：用管理的逻辑了解和使用AI Agent（准备工作&框架）|ChatGPT Work（Codex）之道：用管理的逻辑了解和使用AI Agent（准备工作&框架）]]》中介绍过本系列文章的背景：借用管理中的领导、组织、控制和计划四项职能，梳理 ChatGPT Work 的相关功能，从而能够更方便地理解、记住和使用这类 AI Agent。
上一篇已经介绍了最基础的内容：安装登录、认识界面、选择项目和工作目录、开展任务等。从这一篇开始，我们将按照领导、组织、控制和计划的顺序逐一展开。
管理学中的领导，是指管理者通过沟通、激励、引导等手段来影响团队成员，从而使之能够实现组织目标的过程。领导 AI，也需要通过沟通影响大模型对任务的理解、判断和行动，使它朝着我们设定的目标工作。
管理和领导要懂人性，管理和领导 AI Agent，也要懂一点“AI 性”。AI 继承了人的一些特点，但它理解任务和延续经验的方式，又跟人不完全一样。人可以通过沟通、激励等方式影响人，AI 则没有愿不愿意工作的区别。在模型和产品已经确定的情况下，我们能够持续影响AI的主要抓手，是提供给大模型的上下文。
本文以最新版的 ChatGPT Work 为主，围绕着大模型上下文、任务（对话）管理、用户指令（AGENTS.md）、记忆（Memory）、技能（Skills）和子Agent（Subagents）等内容展开介绍。文中所说的 ChatGPT Work，仅指 ChatGPT 新版桌面应用中处理本机项目的Work本地模式，不包括在云端运行的 Work 模式。本地版 ChatGPT Work 与 Codex 目前基本采用同一套运行逻辑，所有内容也适用于Codex。需要说明的是，由于 ChatGPT 新版桌面应用仍在快速迭代中，涉及到具体的功能入口和名称等，可能会随着版本更新发生变化。
1 大模型和上下文
要说明怎样领导 AI Agent，首先需要说清楚大模型怎样获得上下文，以及上下文为什么会影响它的工作。理解了这些基础逻辑，我们才能更好地与 AI 沟通，让它更稳定地完成任务。
1.1 上下文
大模型简单来说，就是一个根据输入内容，一顿计算后输出新内容的机器。它每次生成回复，都是一次独立的计算：接收输入、给出输出，然后就没有然后了。
也就是说，大模型本身并不会保存上一次计算发生了什么，每次生成回复时，它能够直接参考的，只有这一次所收到的所有信息，这些信息就叫作上下文（Context）。除此之外，它没有另一套可以随时调取的内部记忆或知识库供它参考。大模型虽然确实“知道”很多东西，但这些知识已经在训练过程中融入模型参数，并不存在一套可以临时查阅的资料。
但无论是简单的聊天机器人，还是复杂的 Agent 产品，我们和它们交流时，却都像是在跟一个有记忆的“硅基人”交流——似乎大模型能够记住我们沟通过的内容。
但其实，这并不是模型自己保存了之前的信息，而是我们使用的这些产品在每次调用模型生成回复时，都会把用户最新的提示词、此前的对话以及其他所有相关信息汇总起来，一把发给大模型。大模型每次都重新看一遍这些内容，所以能够表现得像是“记得”很多东西一样。
1.2 上下文窗口
随着一轮对话和任务的持续进行，对话内容和任务执行信息不断叠加，每次发给大模型的内容会越来越多。但是，大模型一次能够处理的信息量是有限的，超过模型能够处理的上限，请求就无法正常完成。这个上限就叫作上下文窗口。上下文窗口通常用 token 数量衡量，不同模型和版本之间差别很大，有的是数十万 token，有的则达到百万 token。
在实际使用中，很多产品会在真正达到模型的上下文窗口之前，就主动处理已经过长的上下文，比如舍弃较早的内容，或者把此前的信息压缩成摘要。
但是，即便当前交流中的上下文没有达到上限，也没有触发自动压缩或者截断，过多的上下文内容积累，仍然可能影响输出质量。一方面，无关的信息和过多的细节会淹没当前真正需要注意的内容，使模型更容易抓错重点；另一方面，上下文内容长度增加本身，也会降低大模型的输出表现。
所以，对于同一个模型来说，衡量 AI Agent 使用水平的一个重要标准，就是能不能在给大模型提供足够信息的同时，尽量避免上下文过长。这就需要界定发给大模型的“其他所有相关信息”中的“相关”：哪些信息真正需要提供，哪些应该排除，又该怎样组织。这个问题既考验产品设计者，也考验使用的人。围绕上下文展开的这套管理工作，AI 界称为“上下文工程”。
1.3 上下文工程
具体来说，上下文工程需要管理提供给模型的信息，让模型在当前任务中获得有效的“工作上下文”。不同 Agent 产品组装上下文的方式并不完全相同。为了便于理解，我们这里根据信息由谁维护、在什么范围内生效，将上下文信息整理为下面 3 组 8 类。
第一组，产品级：产品预设，用户了解即可
这一组上下文由产品开发者预先提供，用户不必参与维护，可以简单了解它们会怎样影响 Agent 的工作。
- System Instructions（系统指令）：由产品提供给大模型的高优先级指令，用来规定 Agent 的角色、职责和必须遵守的基本规则。它们会随每次请求一起提供给大模型，通常不对用户开放。
- Built-in Tools（内置工具）：每次调用大模型时，产品都会发送当前可用内置工具的名称、用途和调用参数，让模型知道有哪些工具可以使用以及怎样调用。这些内置工具由产品直接提供，例如读取文件、搜索网页、执行命令或者操作其他软件等。
第二组，用户级/项目级：长期生效，用户可以配置和建设
这一组上下文可以在不同任务之间长期生效。用户级上下文作用于本机当前登录的用户所开启的所有项目和任务，项目级上下文则只作用于某一项目中开启的所有任务。用户和 AI 可以在使用过程中持续配置、建设和更新这些内容，也是用户进行上下文管理的核心。
- User Instructions（用户指令）：用户为 Agent 设置的长期工作要求，可以在用户级或项目级生效。不同 Agent 产品用不同的文件保存这些要求，例如
AGENTS.md、CLAUDE.md和SOUL.md。 - Installed Tools（安装的工具）：用户可以在内置工具之外为 Agent 增加新的工具，包括用户安装的 Plugins（插件）、启用的 Connectors（连接器）或配置的 MCP Servers（MCP 服务器）等。启用后，相关工具的名称、用途和调用参数会随请求一起提供给大模型。
- Memory（记忆）：产品在不同任务之间保留并在需要时引用的信息，例如用户偏好、项目背景和以往经验。但不同产品保存和调用记忆的方式不同，有的产品Memory（记忆）和User Instructions（用户指令）在形式上的差别并没有那么明显。
- Skills（技能）：由指令和辅助资源组成的可复用工作流程，每次向大模型请求回复时，都会把当前任务（对话）可用的技能名称、简介和文件路径放入上下文；当用户明确调用某项技能，或者模型认为当前任务与某一项Skill匹配时，模型才会主动读取完整的
SKILL.md及其参考资料和脚本。这种按需发送上下文的方式，极大地扩展了模型的能力。
第三组，任务级：动态产生，随任务积累
这一组上下文在任务进行过程中动态产生，包括你与 AI 的对话，以及 Agent 调用工具后得到的输出。随着任务推进，对话和工具调用输出都会不断积累。
- Conversation（对话）：用户与 Agent 在一项任务中持续交换的消息。大模型本身不会自动保留上一轮内容，产品需要在后续调用中继续提供此前的对话内容，以维持对话状态，让模型理解前因后果。
- Tool Call Outputs（工具调用输出）：大模型发出工具调用后，Agent 产品会执行相应工具；工具返回的内容就是工具调用输出，例如读取到的文件内容、网页搜索结果或命令执行结果等。产品会把这些输出提供给大模型，让它据此决定下一步做什么。
产品级上下文由产品预设，了解即可；安装和配置工具主要改变 Agent 可以调用的工作资源，放在“组织”一篇中展开。本文接下来主要介绍如何通过压缩上下文、隔离任务，管理不断积累的对话历史，如何建设和维护可以跨任务复用的用户指令、记忆和技能，如何借助子Agent拆分复杂任务，进一步隔离上下文。
2 任务（对话）管理
正如前面介绍过的，ChatGPT Work 以独立的任务（对话）展开工作，如果什么事都在同一个任务里做，这份历史只会越积越长，里面装的事情也越来越杂：太长，就容易触碰上下文窗口的限制，触发压缩、损失信息；太杂，模型判断时受到的干扰就越多。
所以需要有意识地对任务进行管理，平时可以关注一下当前任务占用上下文窗口的比例。随着工作的推进，接下来要处理的事情与当前任务关联不大时，尽量新建任务单独处理，同一项工作还要继续，但上下文占比已经较高、输出质量开始下降时，可以考虑主动压缩；中途冒出一个与后续工作关系不大的疑问时，开一个侧边任务沟通，而不打断主任务；原有背景仍然有用，但想换一条路线继续时，把任务分叉出去。
背景信息窗口（上下文窗口）：输入框右下角的圆环会显示背景信息窗口的已用比例；将鼠标移到圆环上，还能看到已经使用和总共可用的数据。这里的“背景信息窗口”，就是前面说过的上下文窗口。前面介绍的所有上下文都会占用这个窗口，随着任务不断推进，发送给大模型的内容通常会越来越多，占用比例也会随之上升。
上下文压缩：同一项工作还要继续，但上下文占比已经很高时，可以输入 /compact 或 /压缩，让 ChatGPT Work 把此前的对话记录和工具调用输出概括成摘要，在保留主要信息的同时腾出更多空间。即使没有手动输入命令，上下文长度接近窗口上限时，ChatGPT Work 也会启用自动压缩，以便让当前任务继续进行。
新建任务：如果接下来要处理的事情与当前任务关联不大时，尽量新建任务单独处理，不让两件事情的对话和工具调用输出混在同一个上下文里。具体可以直接点击 ChatGPT 主界面左上角的新建任务，也可以点击项目右侧的铅笔图标。
侧边任务：处理主任务时，如果临时冒出一个需要当场确认、但不会影响后续工作的疑问，可以输入 /side 或 /副任务，或者在右侧面板新建侧边任务。侧边任务可以使用主任务已有的上下文，因此不必重新交代背景；侧边对话不会写回主任务，也不会继续占用主任务的上下文窗口。
分叉任务（Fork）：ChatGPT Work 目前把这个功能称为“新任务中继续”。它会把当前任务到目前为止的记录复制到一个新任务中：原任务保持不变，新任务带着相同的背景沿另一条路线继续。它适合已有背景仍然有用、但想尝试另一种方案的情况。
3 用户指令（AGENTS.md）
3.1 AGENTS.md是什么
AGENTS.md 是一份放在约定位置的 Markdown 文件，开始一项任务时，ChatGPT Work 会读取当前范围内生效的 AGENTS.md，并把其中的内容加入发给大模型的上下文中。因此，只要新任务处在该文件的生效范围内，这些要求就会被自动加载，这样就不用在每个任务中重复交代。
AGENTS.md 已经成为许多 AI Agent 产品支持的开放格式，但一些产品仍有自己默认的用户指令文件，比如 Claude Code 使用 CLAUDE.md。它们的名称虽然不同，但本质是一样。
AGENTS.md 通常分为两个层级，文件所在的位置决定它在哪些范围内生效：
（下面路径中的 ~ 表示当前用户的主目录。在 Windows 中通常是 C:\Users\你的用户名，在 macOS 中通常是 /Users/你的用户名，在 Linux 中通常是 /home/你的用户名。）
- 全局文件
~/.codex/AGENTS.md：放在当前用户的 ChatGPT Work 配置目录中，对本机上由该用户打开的所有项目生效。适合存放每个项目都用得上的要求，比如“始终用中文交流”。写在这里，就不必在每个项目中重复交代。 - 项目文件：放在项目根目录，只对当前项目生效。只有这个项目才需要知道的规则适合放在这里，比如知识库里各类笔记分别放在哪里——换一个项目，这条规则就没有意义了。
全局文件 ~/.codex/AGENTS.md 既可以直接用编辑器修改，也可以通过 ChatGPT Work 桌面版的“设置 → 个性化 → 自定义指令”修改。直接编辑这个文件并重启 ChatGPT Work 后，界面中的自定义指令会随之更新；反过来，在界面中修改并保存自定义指令，内容也会写回这个文件。
3.2 写什么
AGENTS.md 适合用来存放用户主动编写和维护的长期信息和工作要求，这些要求最好是 Agent 开展大多数任务都需要知道的内容，具体写什么没有统一答案，更多还是要在使用中慢慢摸索。个人的判断是：大多数任务都需要，但又不能指望 Agent 靠临时查阅项目文件快速、准确获得的信息，优先写进 AGENTS.md。
按这个标准，适合写进 AGENTS.md 的信息主要有两类：一类是项目文件中没有的，比如你定下的工作要求、偏好和禁止事项，Agent 无法通过查阅项目文件自行得知；另一类是项目文件中虽然有，但每次临时查找既占用上下文又容易遗漏的，比如项目的整体结构等。
例如，我自己笔记库的 AGENTS.md，大致写了三类内容：一是仓库介绍——这个笔记库是干什么的、主要目录有哪些；二是工作要求和纪律——比如修改文件前必须先征得同意、敏感信息不许记录等；三是工作流程——文献笔记、闪念笔记、永久笔记和发布笔记分别是什么，怎么流转等等。
但是，也不能什么要求都写进 AGENTS.md。内容过多不仅会淹没真正重要的规则，还会在每次任务中持续占用上下文。有些要求只在特定类型的任务中才会用到，更适合做成 Skill：具体我们将在后面展开。
3.3 如何管理和维护
初始化：如果项目已经有了一定的文件和结构，可以输入 /init或/初始化，让 ChatGPT Work 分析项目现状，生成一份 AGENTS.md 初稿。如果项目还是空的，没有足够的信息可供分析，就不必急着使用 /init。如果你已经有一些明确的规则和需求，可以直接告诉 AI，让它先提炼整理成一份简单的 AGENTS.md，以后再根据实际使用逐步补充和调整。
在使用中迭代：如果你发现 AI 反复犯同一类错误，就可以考虑把纠正错误所需要的原则、事实、规则等写进 AGENTS.md；或者你发现自己在不同的任务中反复给AI输入相同的信息，也可以考虑把这类信息写进 AGENTS.md。你既可以直接修改，也可以让 ChatGPT Work 协助修改，还可以让AI 自行审查其中的内容。
多 Agent 共用 AGENTS.md：如果同时使用多个 Agent 产品，而这些产品都支持 AGENTS.md，那就最完美了，一份文件在多个产品中都可以用。对于像 Claude Code 这种比较特立独行的，也可以让 AI 把 Claude Code 使用的 CLAUDE.md 设为指向 AGENTS.md 的软链接，这样就还是可以只维护一份文件，让各个产品的Agent都能读到。软链接可以理解为系统中的“快捷方式”，两个文件名看起来都存在，实际读取和修改的是同一份内容。
4 记忆（Memory）
除了你主动维护的 AGENTS.md，很多 Agent 产品还会提供自动记忆功能，ChatGPT Work 也不例外。在“设置 → 个性化 → 记忆”中打开“启用记忆”即可。在具体任务中，还可以输入 /memories，单独控制当前任务是否读取已有记忆，以及是否允许产品根据这次任务生成新的记忆，不影响全局设置。
记忆功能的基本逻辑并不复杂：产品通过模型判断哪些信息可能对以后有用，将这些信息保存到记忆系统中；以后的任务需要时，再把相关记忆带入大模型的上下文。具体怎样生成和加载，不同产品的实现并不相同。
从生成记忆的方式来看，有的产品会让模型在任务进行过程中边对话边记录，有的产品会等任务空闲后再调用模型，对任务记录进行总结和提炼，也有的会同时采用这两种方式。ChatGPT Work 采用的是空闲后生成的方式：等符合条件的任务闲置一段时间后，再在后台提取有用信息并生成记忆，相关文件保存在 ~/.codex/memories/ 下。
从加载记忆的方式来看，有的产品只维护一份精炼的记忆文件，像 AGENTS.md 一样每次带入上下文；有的产品则采用分层记忆，默认加载精炼内容，需要时再查找详细记录。ChatGPT Work 采用的是后一种方式，它的本地记忆大致分为三个层次。
第一层是记忆概览。任务开始时，memory_summary.md 会被默认发送给大模型，其中是经过高度压缩的整体记忆概览，帮助大模型了解现有记忆大致包含哪些内容。
第二层是记忆索引。大模型根据当前任务判断是否需要调用过去的记忆；如果需要，就根据任务中的关键词查找 MEMORY.md。它并不是完整的历史记录，而是一份带有内容摘要的索引，其中记录了不同任务主题的关键词、用户偏好、可复用经验、曾经出现的问题，以及相关详细记录的位置。
第三层是详细记录。如果 MEMORY.md 中的信息还不够，大模型才会顺着其中的指向，读取少量相关的任务复盘和证据片段。例如，rollout_summaries/ 中保存了过去任务的详细总结。因此，默认进入上下文的只有第一层记忆概览，第二层和第三层都是大模型根据当前任务按需查找和读取的。
主动管理：因为记忆是大模型自己判断和生成的，所以一般不需要用户去管。但是有空的时候，偶尔查看一下也不是不行。发现错误或过时的内容，可以让 ChatGPT Work 修改或删除。在使用过程中，如果有些信息希望它以后还能记得，也可以在任务中明确告诉它“记住这件事”。
5 技能（Skills）
5.1 Skill 是什么
技能（Skills） 是为某一类任务准备的一套可重复使用的工作指南，告诉 Agent 这类任务适合在什么情况下处理、应该经过哪些步骤、依据什么标准判断，以及最终交付什么结果。
从文件上看，一份 Skill 通常是一个独立目录，核心文件是 SKILL.md。文件开头的 name 和 description 用来说明它叫什么、能做什么以及什么时候应该使用，正文记录具体的工作要求和流程。目录下还可以根据需要设置 references（参考资料）、assets（资源文件）和 scripts（脚本）等子目录：references 用来存放完成任务所需的知识和规则，assets 可以存放模板、示例以及最终交付时需要使用的文件，scripts 则用于数据处理、格式转换等可以直接执行的脚本。
Skill 可以作为插件的一部分安装，也可以以独立文件夹的形式使用。无论采用哪种方式，Skill 文件夹中都需要包含符合格式的 SKILL.md 文档，文档中需要按照规定格式写明 name 和 description。如果 Skill 随插件提供，在 ChatGPT Work 的插件页面安装并启用插件后，其中的 Skill 就会进入可用范围。关于插件，我们将在《组织篇》中具体介绍。如果直接使用独立的 Skill 文件夹，这个 Skill 既可以由自己创建，也可以从别人那里获得，但需要放到 ChatGPT Work 能够扫描的目录中。
独立的 Skill 文件夹通常可以放在两个位置。用户级 Skill 放在 ~/.agents/skills/技能名/，ChatGPT Work 在处理本机不同项目时都可以使用，适合存放不依赖某个具体项目的通用工作方法。项目级 Skill 放在项目根目录下的 .agents/skills/技能名/，只在处理这个项目时使用，适合记录项目特有的工作流程、判断标准、模板和参考资料。简单来说，多个项目都会用到的 Skill 放在用户级目录，只服务于一个项目的 Skill 放在项目目录中。
对于当前任务可用的 Skill，Agent 不会一开始就把它们的完整内容都放进上下文，而是先向大模型提供一份包含 Skill 名称、简要描述和文件路径的清单。这样，尚未被选中的 Skill 只占用少量清单信息；只有被选中以后，其完整内容才会进入上下文。
当我们告诉 ChatGPT Work 要完成什么任务时，它会根据清单中各个 Skill 的 description 和当前任务，判断有没有适合这项任务的 Skill；如果选中某项 Skill，再读取相应的 SKILL.md 和辅助文件。另外，我们也可以直接手动选择 Skill：在桌面版的输入框中输入 / 或 $，选择需要使用的 Skill。
5.2 Skill 的适用场景
要让 AI Agent 把一项工作做好，通常不是给它一句简单提示词就够了。比如做一项上市公司数据整理工作，看起来只是“整理数据”，但实际会涉及数据从哪里获取、是让 AI 用代码直接抓取还是操作浏览器去取、要获取哪些数据、每个数据口径是什么、最后按什么格式输出等一系列问题。如果每次都临时写提示词告诉它怎么干，就很容易漏步骤、过程出错、口径对不上，甚至反复出现之前已经纠正过的问题。
这个时候 Skill 的作用就体现出来了。Skill 的价值不只是少写几遍提示词，更像是企业里的业务流程——把完成一类工作的有效方法沉淀下来，让 ChatGPT Work 不再完全依赖临场发挥，而是能够端到端地交付工作成果：同一类任务不用每次都从头解释，而是按相对固定的流程做事，这样就不容易漏步骤、换口径或者重复犯以前已经纠正过的错误，输出结果更稳定。
当然，像业务流程一样，Skill 也能实现一定程度的风险管控。比如一项工作里有些关键节点不能让 AI 自己拍板，就可以在 Skill 里要求它先停下来跟你确认，而不是自行决策和处理。刚开始创建一个 Skill 时，可以多设置几个确认节点，等流程跑顺、可靠性得到验证之后，再逐步减少确认，最终让 AI 直接交付成果。
并不是所有任务都需要做成 Skill。那些经常重复、需要反复交代相同要求、已经形成相对稳定步骤，并且有明确交付成果的任务，通常才更适合做成 Skill。其中，容易遗漏环节、混淆口径、重复出现同类错误，或者需要固定检查和确认节点的工作，尤其值得做成 Skill。Skill 也不只适合记录操作流程；某类任务需要用到的专业知识、判断标准、写作规范和参考材料，也可以放进 Skill，在处理相关任务时再提供给 ChatGPT Work。
5.3 如何创建、迭代和管理 Skill
创建初版：创建 Skill 不需要我们自己研究格式、手写文件。更合适的方法是：第一次完整做完一项真实任务后，就让 ChatGPT Work 根据刚才的执行过程创建一份初版 Skill。这样，它可以直接从真实过程里提取任务的输入、执行步骤、判断标准、确认节点和交付要求。初版 Skill 不必追求完善，先把已经做过的流程记录下来，后续再通过一次次实际使用不断优化。
创建时可以调用 skill-creator，这是一个专门用于创建 Skill 的技能。让它根据刚才完成任务的过程创建一份 Skill。生成之后，可以简单看一遍，也可以先直接用起来，后续再根据实际使用中出现的问题慢慢调整。
在使用中迭代：很多问题只有在实际使用中才会暴露出来，例如触发条件不准确、步骤顺序不合理、确认节点过多或过少、参考资料没有在正确时机读取、交付结果仍不稳定等。遇到问题不要只在当前任务中纠正一次，还应把正确的规则和经验沉淀回 Skill。
因此，建议准备一个专门用于复盘和优化其他 Skill 的技能，例如 skill-improver。某个 Skill 实际使用一次以后，再调用 skill-improver 检查这次执行中出现的问题，并更新原来的 Skill。这样会形成一条持续改进的路径：完成真实任务 → 创建 Skill → 在同类任务中使用 → 复盘执行问题 → 更新 Skill。
只不过，让 AI 优化 Skill 也有局限：有时让 AI 改了好几轮，问题仍然没有解决；有时 AI 的修改只是不断往 Skill 里加新规则，导致规则越堆越多——这时候可以考虑自己直接编辑 SKILL.md 来改。
另一方面，随着模型能力提升，过去为了防止模型出错而写得很细的步骤，后面可能不仅没有必要，反而还会限制 AI 做出更好的选择。据公开报道，Anthropic 最近将 Claude Code 的系统提示词缩减了约 80%。其技术人员解释，新一代模型需要的具体指令和示例更少，过多的限制反而可能影响模型发挥。系统提示词和 Skill 并不是一回事，但背后的道理相通：模型升级以后，也要重新检查过去积累的规则，判断哪些仍然是必要的工作要求，哪些只是为了弥补旧模型能力不足而留下的补丁。
定期整理：长期不用、功能重复或者已经不符合当前工作方式的 Skill，应当删除或合并。Skill 不是越多越好；只保留真正服务于自己使用场景的内容，ChatGPT Work 才更容易准确选择和执行。
5.4 跨 Agent 复用和管理 Skill
Skill 已经形成相对统一的文件格式。一份在 ChatGPT Work 里创建的 Skill，其内容也可以在 Claude Code、OpenClaw、Hermes 等支持这种格式的 Agent 产品中继续使用，不需要为每个产品重新编写。因此，自己创建 Skill 的投入产出比还是非常高的。
但是，不同 Agent 默认加载 Skill 的路径可能不同。如果为了让每个 Agent 都能找到它，分别把同一份 Skill 复制到各自的目录中，就不太好管理。更好的做法是让多个 Agent 共用同一份——Skill 放在统一的 .agents/skills/ 目录里，支持这个路径的产品（如 ChatGPT Work、OpenClaw）直接加载；不支持的产品比如 Claude Code，可以让 AI 将它使用的 .claude/skills/ 设为指向 .agents/skills/ 的软链接。这里链接的是整个 Skill 文件夹，与前面3.3节链接单个文件略有不同，但作用相同。
如果还要在多台电脑或不同系统上使用同一套 Skill，需要另外设置文件同步。用户级 Skill 可以通过网盘、Git 等方式同步 ~/.agents/skills/ 目录；项目级 Skill 通常跟随项目文件一起同步。无论是跨 Agent 还是跨设备，核心都是“一份 Skill 多处使用”。
6 子Agent（Subagents）
上下文隔离：子Agent本质上是上下文隔离的一种方式。前面讲过，复杂任务如果都在一个对话里处理，上下文会越来越长、越来越杂，影响模型输出质量。这个时候，主Agent可以把任务拆成若干相对独立的部分，再分别分配给不同的子Agent。每个子Agent只保留自己所负责部分的上下文，不把无关信息混在一起，主任务的上下文也能保持清爽。子Agent的价值因此不只是“人多力量大”，也在于隔离上下文。
子Agent是什么：子Agent是主Agent在需要时临时启动、专门负责某一部分工作的 Agent。每个子Agent都有独立的任务和上下文，只接收完成自己那部分工作所需的信息。完成后，它会把结论和必要信息交回主Agent，由主Agent统一汇总；中间产生的大量对话和工具调用输出不会原样全部塞回主任务。
内置与自定义子Agent：这里需要区分运行中的子Agent和定义其角色的配置文件。运行中的子Agent，是主Agent为某项工作临时启动的任务执行者；配置文件则像一份提前写好的岗位说明书，规定这个角色叫什么、适合做什么、应当遵守哪些要求，以及使用什么模型、工具和权限。
有些岗位说明书已经由产品内置。Codex本地客户端内置了三个通用角色：default负责一般任务，worker侧重执行修改和实现，explorer侧重查阅文件和了解项目。ChatGPT Work也可以根据主Agent的分工临时启动专门化的子Agent，但官方目前没有公布一份固定的角色名单。
如果希望子Agent长期承担某种专门分工，就可以自己创建一份角色配置文件。Codex的自定义子Agent使用独立的 TOML 文件，通常放在用户目录下的 ~/.codex/agents/，或者项目中的 .codex/agents/。主Agent选用这个角色时，Codex会读取相应的配置文件，再按照其中的要求启动子Agent。
怎么调用：调用子Agent有两种方式。第一种是直接在指令中要求主Agent分派工作，可以指定子Agent的数量和分工，也可以让主Agent根据任务自行拆分；如果需要等所有子Agent完成后再继续，或者希望最终按照特定格式汇总，也可以一并说明。
第二种是指定某个自定义子Agent。至少在我当前使用的桌面版中，在输入框中输入 @ 后，候选列表显示的是用户已经创建或导入的自定义角色，default、worker和explorer这些内置角色并不在其中。内置角色仍然由主Agent在分派任务时选择，不能直接从 @ 列表中调用。选择自定义子Agent以后，还需要在后面写明具体任务：@解决的是“让谁来做”，并不能代替任务要求。
如何使用：我自己比较少使用子Agent，所以目前还没有形成稳定的使用方法。从产品目前提供的内置角色和工作方式来看，它更适合能够拆成多个相对独立的部分，并交给不同Agent自动推进的代码工作。如果任务本身无法独立拆分，使用子Agent反而会增加协调成本。
兴之所志